In general, VDS approaches in the prior art include similar features. For example, many VDS approaches offer aggregation of user stores, and many VDS approaches provide an LDAP interface to allow for communication between clients.
Many VDS approaches have similar limitations, including the inability to offer a uniform authentication interface: While most VDS products offer the ability to interface with any supported user stores, the bind status and control codes vary greatly depending on the backend software and are left to the client software to decipher.
VDS approaches also typically lack a coherent business rules layer: While most VDS products offer the ability to insert business code into the software via “interceptors”, an extensible rules layer which allows for declarative rules defined in natural English statements has not been developed as of yet.
VDS approaches are also very inflexible with respect to dynamic changes in configuration files. While most VDS products offer an application or configuration file where static definitions and information about the supported user stores can be input, the configuration is local to the server and must be taken offline to be updated. This is largely because no current product offers critical integration with the de facto enterprise discovery mechanism, provided by a service discovery mechanism, such as the UDDI service discovery protocol, for example.
Another disadvantage of typical VDS approaches is that while it is possible to discover services, the nature of the discovered services is not always apparent. Thus, an address and connectivity to a device at the address may be obtained, but the nature of services offered by that device through the connectivity is not provided. In some cases, an initial connection response or directory entry is provided, but if the nature of the connection or device is not apparent from the initial connection response or directory entry, then it unclear whether the address includes the desired services.